Over recent years, Information/Content Centric Networking (ICN/CCN) is gaining momentum as a future technology for 5th generation mobile networks (“5G”) and other coming technologies for media distribution, device software upgrades and the Internet of Things (IoT).
Information Centric Networking and Content Centric Networking are sometimes also referred to as Named Data Networking (NDN). In the following, the term ICN will be used to encompass ICN, CCN and NDN technology.
ICN may be utilized for delivery of content to a wireless communications device, commonly referred to as a User Equipment (UE), over e.g. a 3rd Generation Partnership Project (3GPP) network, where the UE may be embodied in the form a smart phone, tablet, laptop, a gaming console, etc., or a so called fixed wireless terminal (FWT) in the form of e.g. a television set, a computer, or a set top box.
In contrast to traditional Internet Protocols (IPs), ICN addresses content objects using globally unique names instead of IP addresses.
FIG. 1 illustrates a general operating principle of prior art ICN content request and delivery. This operating principle assumes that a link used in one direction—e.g. between ICN Node 1 and ICN Node 2 essentially being switches equipped with large caches for transporting content—to send content requests from subscribers is also used in the other direction to send the corresponding content back via ICN Node 1 and ICN Node 2 from a content provider to the subscribers. All links in ICN are therefore assumed to allow for bi-directional communication. A request in ICN terminology is commonly referred to as an “interest”.
Multicast support is a key feature in ICN when transporting a particular content from a content provider to various subscribers/end users whom have requested content from that particular content provider. Whenever a node which has received content requests from several subscribers over different interfaces (each node being illustrated to comprise four interfaces in FIG. 1) receives requested content available for delivery, the node will deliver the requested content to the subscribers over a respective interface.
With reference to FIG. 1, if both Subscriber 1 and 2 request the same content, e.g. a live video stream, both subscribers will submit a request/interest to ICN Node 1. However, ICN Node 1 will only forward a single request to ICN Node 2 for that video stream, and ICN Node 2 will as a result forward the single request towards the content provider. The content provider will thereafter return a single copy of the requested live stream to ICN Node 2. Likewise, ICN Node 2 will only send one copy of the live stream over its link to ICN Node 1. ICN Node 1 will then replicate the content of the video stream and send it to both Subscriber 1 and 2.
To the contrary, should ICN node 1 already have the requested content in its cache, it will deliver the content to the requesting subscriber(s) without submitting any further upstream request to ICN Node 2.
The routing of interests is helped by the name of a requested piece of content being a structured name (similar to domain names, but with richer syntax). Routing ICN nodes maintain a Forwarding Information Base (FIB) about where, i.e. across which interface, the name or name prefix should be forwarded. The routing ICN nodes along the path of the travelling interest message keep a record of the interest messages they have forwarded (the interface it came from and the content object it was naming) in their Pending Interest Table (PIT).
As can be concluded, when the interest message reaches an ICN node having a copy of the content object, the content object is propagated backwards along the path the interest message took. The backward path is learned from the entries the interest message left in the PIT of the ICN nodes along the path. If there were multiple interests arriving at an ICN node for a content object address by a particular name, the content object is replicated towards each respective interface/direction the interest messages came from. After forwarding a content object matching a pending interest, the ICN nodes delete the corresponding entry in the PIT. When the original endpoint(s) generating the interest message(s) receive the content object, the transaction is considered finalized.
If other interest messages addressing the same content object arrive at a routing ICN node, it does not forward them, just notes them in the PIT along the entry for the named content object, which is referred to as interest aggregation. This way the PIT entries for the same name (i.e. the same content object) may form a tree in the network with receiver of the interests as the leaves. Interest aggregation is particular advantageous in case of a flash crowd event where suddenly thousands of endpoints are requesting the same content, since the source will only be reached by one request for the content, all other requests will be served from the caches of routers along the path towards the source.
As can be concluded, ICN technology provides for an efficient, scalable and flexible approach of delivering information to an end-user.
A problem with implementing ICN technology in wireless communication networks is that there is no way for the UE to know whether the network with which the UE connects is capable of setting up a connection with an ICN node, i.e. whether the network is ICN compatible.
In the art, when a client such as the mentioned UE requests ICN content, it periodically sends ICN interests addressed and routed by means of the name of the requested ICN content as described in the above, and it will do so either until a preset timer expires, or after a predetermined number of ICN interests have been sent (or until the client ultimately is granted ICN access), which causes signalling load on the network. Further, since the time from the sending of an ICN interest to the instant where it can be concluded that the requested ICN content is not returned back (due to variations in network conditions)—and the ICN interest is re-submitted—may be relatively long, it is a risk that the user of the UE will perceive Quality of Experience (QoE) as being low.